From: TIM FARLEY Read: 10-11-90 (19:55)
Date: 10-08-90 (14:52) Number: 573 / 588 (Echo) To: DENNIS EDWARDS Refer#: NONE

Still having some intermittent lockups on our BBS.  It's gotten
very frustrating, because they leave no useful evidence behind,
and typically occur only when the system has been left
unattended.  Some of these lockups feature some I/O redirection
(console output redirected into a file that happened to be open)
of the type I previously described.  Others frequently revolve
around an apparently "unhooked" comm port IRQ.

Anyway, all that aside, my investigation lead me to believe that
perhaps PCBoard 14.2 uses the "ICA" area of memory.  Since I
didn't have /D:ICA on my OV command line, this could be a
problem.

I'm still waiting to hear a definitive answer from CDC on this
question, meanwhile I decided to investigate.

However, I'm not the type to just blindly add a command line
option and hope, so I decided to probe a little.  I wrote a
program that would continuously dump the ICA, and ran it in one
partition, while I vigorously excercised the operating PCBoard
node in the other partition.  I saw no change from 16 bytes of
00's during the run.

So then I manually altered a few of the bytes of the ICA, to see
if they would show up in the dump in the other partition.  They
didn't!

I found I was able to fill the two ICA's in the two opposite
partitions with specific (unique) values, without interfering
with one another.  All this *without* the string "/D:ICA" on any
of my command lines.

Which leads to the question:  if OV 4.13 is already preserving
the ICA over task switches anyway, just what does "/D:ICA" do?

--Tim Farley

Date: 10-09-90 (19:17)              Number: 574 / 588 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: TIM FARLEY                      Read: 10-11-90 (19:55)
Subj: AMRS SETTINGS                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Quick question:  If I have the AMRS parameter set too low on my memory
manager, will it affect OV's performance even if I am not allowing any
of the tasks to swap?

Date: 10-09-90 (19:21)              Number: 575 / 588 (Echo)
  To: DENNIS EDWARDS                Refer#: 569
From: TIM FARLEY                      Read: 10-11-90 (19:55)
Subj: NEW OMNIVIEW VERSION!         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>386-Mate: NEW!
>    Interrupt handlers can be swappable.

I assume you are referring to interrupt handlers within OV while it is
running, right, like comm programs that are operating inside an OV
partition?

>OMNIVIEW:
>    User written OMNIVIEW device drivers support. You can now get
>        configuration information when a new process is created
>        (passed with the USR_ALLOC signal in DS:DX as part of the
>        "DOS" device parameter string). I'll post more on this
>        later - it's implications are significant.

I am very much interested in hearing more about this as soon as you get
some time.

--Tim Farley

Date: 10-09-90 (19:24)              Number: 576 / 588 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: TIM FARLEY                      Read: 10-11-90 (19:55)
Subj: OMNIHIGH and XMS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I haven't gotten my 4.20 upgrade yet, (but it's supposed to be on the
way), so this question may sound stupid.

Has OMNIHIGH been made XMS-aware in 4.20?

The reason I ask, is in 4.13, in order to use OMNIHIGH, you have
to give 48K of RAM to the EMS manager to remap into somewhere
other than the normal EMS page frame.

Unfortunately, that's 48K of memory that *can't* be allocated to
loading TSR's.

That may sound silly, since obviously if I loaded TSR's in that
memory, I wouldn't be able to load OMNIHIGH there, right?  But
it's not that easy---because of the vagaries of TSR loading, I
have to have alot more memory available up high during the load
process, than the TSR's actually need.  SUPERPCK, for instance,
in my configuration, uses about 58K while initializing, but only
16K when resident.

So, I end up with an amount of RAM up above my TSR's that are
loaded high, that is effectively wasted---I don't have any more
TSR's to load there, but OMNIHIGH won't allocate it.

Finally, Tim gets to the point:  because of the way that 386-MaX
works (and QEMM 5.x may or may not be the same way, I haven't
checked), the memory that is used for loading TSR's HIGH *can* be
shared with the XMS "Upper Memory Block" calls, and it in fact
is.  But memory allocated for EMS's use in a manner compatible
with OMNIHIGH *cannot* be shared with TSR loading.

Bottom line:  If OMNIHIGH would use the XMS "Allocate UMB" call
to allocate the high memory it needs (if and only if the EMS
calls it makes now do in fact fail) it would be much more
compatible with the "loadhi" functions of 386-Max at least,
possibly also QEMM.

Did that make any sense?

--Tim Farley

Date: 10-12-90 (12:13)              Number: 577 / 588 (Echo)
  To: TIM FARLEY                    Refer#: 573
From: DENNIS EDWARDS                  Read: 10-12-90 (18:20)
Subj: Question about /D:ICA         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

³Still having some intermittent lockups on our BBS.  It's gotten
³very frustrating, because they leave no useful evidence behind,
³and typically occur only when the system has been left
³unattended.  Some of these lockups feature some I/O redirection
³(console output redirected into a file that happened to be open)
³of the type I previously described.  Others frequently revolve
³around an apparently "unhooked" comm port IRQ.

Sorry. The former may be a result of a feature of DOS that can be avoided
when you get 4.20. I don't know what to say about "unhooked" IRQ's. Do
you mean that the PIC/UART is turned off or that the vector has been
changed?

³Which leads to the question:  if OV 4.13 is already preserving
³the ICA over task switches anyway, just what does "/D:ICA" do?

The standard OMNIVIEW devices can have a status, which they tell OMNIVIEW
about after they initialize themselves, which requires them to be
allocated for each user process. Because of the unruliness of certain
BASICs we were forced to assign this status to the ICA device. The ICA
device also saves and restores a variety of data in segment 50h which is
outside of the ICA proper. Other devices not documented as being
mandatory for each process include DOS and OBJQ.

So, BASICly, /D:ICA just takes up space in your .BAT files.

---
 þ EZ 1.30 þ

Date: 10-12-90 (12:13)              Number: 578 / 588 (Echo)
  To: TIM FARLEY                    Refer#: 574
From: DENNIS EDWARDS                  Read: 10-12-90 (18:20)
Subj: AMRS SETTINGS                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

³Quick question:  If I have the AMRS parameter set too low on my memory
³manager, will it affect OV's performance even if I am not allowing any
³of the tasks to swap?

AMRS is a quantity that effects a couple of things. IF you don't have at
eight of them then we figure you're not really running on LIM 4.0
hardware which has various implications. If you have 8 or more AMRS but
(AMRS-1) < tasks then you have a problem since there will not be
hardware storage for the EMS context state. That will slow things down.
On a '386 or later such things are magical and virtual but their
implications are the same as if "real" hardware were involved.

Assuming this is a '386 box, why would you not want to "swap" your
processes out to EMS?

---
 þ EZ 1.30 þ

Date: 10-12-90 (12:13)              Number: 579 / 588 (Echo)
  To: TIM FARLEY                    Refer#: 575
From: DENNIS EDWARDS                  Read: 10-12-90 (18:20)
Subj: NEW OMNIVIEW VERSION!         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

³>    Interrupt handlers can be swappable.
³
³I assume you are referring to interrupt handlers within OV while it is
³running, right, like comm programs that are operating inside an OV
³partition?

Yes.

³>    User written OMNIVIEW device drivers support. You can now get...
³I am very much interested in hearing more about this as soon as you get
³some time.

Please see the description of EXPECT in my General Apology. I'm posting
the source code to this utility along with the latest revision of the .ASM
API on Poverty Rock as I deliver these messages. In addition to being a
"user written OMNIVIEW device driver" it also shows you how to do more
typical OAPI stuff in the framework of a conventional program since it
is both a TSR and a transient utility. That file also includes a front
end filter for use in speeding up searches that you may find interesting.

---
 þ EZ 1.30 þ

Date: 10-12-90 (12:13)              Number: 580 / 588 (Echo)
  To: TIM FARLEY                    Refer#: 576
From: DENNIS EDWARDS                  Read: 10-12-90 (18:20)
Subj: OMNIHIGH and XMS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

³I haven't gotten my 4.20 upgrade yet, (but it's supposed to be on the
³way), so this question may sound stupid.
³
³Has OMNIHIGH been made XMS-aware in 4.20?

OMNIHIGH itself always has been able to use XMS. That is why it says:

          "Could not allocate EMS or upper memory blocks."

when it fails to find high non-DOS memory. If you can map XMS into the
spot where OMNIHIGH loads high now, and if that will give more room for
TSR load, and if you still end up with 48K left over after loading stuff
then by all means: Do It.

But, and it is a BIG BUT, OMNIVIEW does not and cannot use the HMA, which
is a different sort of critter. OMNIVIEW is almost entirely a bunch of
interrupt handlers and they are (by definition) restricted from loading
there. There probably is some stuff that we could have stuck up there.
But it wasn't part of the initial design of the kernal and the device
dispatcher, etc. and so it will take a significant re-write of OMNIVIEW
to accomplish that. Also consider that, DOS 5.0 is rumored to use XMS for
lots of stuff and that could free up a lot of room for everybody else.

386^Max has the Flex Frame option that allows you to temporarily encroach
on the standard EMS Page Frame in order to initialize your TSRs that are
loaded into high memory. 386-Mate doesn't offer that capability.

---
 þ EZ 1.30 þ

Date: 10-12-90 (12:13)              Number: 581 / 588 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: a General Apology (news)      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I wish to offer our apoligies to all who are waiting on OV. The
manuals should at last be back from the printers and so shiny new
packages should be shipping next week. Really.

As an act of atonement, I have made use of the time to write some new
utilities that I think you will like. I have also redone the .ASM OAPI
and that is just now posted on Poverty Rock along with the 2500+ lines
of commented source code to EXPECT. In additition to showing you how a
real program can make use of both the OAPI and OXSI interfaces to
OMNIVIEW, it includes a filter that can be applied to a search string
to speed up searches of English text. This filter could be modified to
work with other types of data that are well understood.

And what is EXPECT, you ask earnestly?
It is a program that watches the screen of another OMNIVIEW partition
and waits for a specific string to appear. This is similar to the
PROCOMM macro language function of the same name except EXPECT works
for data on the screen of any partition. Some UNIX systems support a
similar function. You use it to synchronize a control script with
events in the partition being controlled. It is both a TSR (an user
writtern OMNIVIEW (OXSI) device driver) and a transient program (that
is quite OMNIVIEW (OAPI) specific).

And that's not all, you also get a utility that (re)names a process
from the command line. Another will search for a named process and set
ERRORLEVEL to its console number if it exists. Yet another will keep
the BIOS from dumping the screen of a background partition when you
press the <Prt Scrn> key. And another will block a partition's access
to the mouse so that they will be able to run in the background.

Again, I apologise for the delay and thank you for your patience.

Happy computing.

---
 þ EZ 1.30 þ

Date: 10-12-90 (12:13)              Number: 583 / 588 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: OBJections to objects         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The OAPI is being revised, redocumented, broken up into language
specific components and being made available by MODEM. The first
step in this process has taken place and exists in the form of
Rev. 4.20 of the .ASM OAPI file. This includes details of the
OMNIVIEW eXternal System Interface (OXSI) used to construct
OMNIVIEW device drivers. A real working progam is included which
utilizes both interfaces and has some interesting features.

We would like to give you what you want if we can. I am intersted
in feedback on the .ASM OAPI contents.

I am particularly interested in knowing the interest level in the
construction of an OOP interface. Any thoughts you have on the
composition of the object and what languages you would like to see
them in first (it will be .ASM by default) will be seriously
considered.

Please leave any thoughts you may have here. Perhaps some helpful
dialogue will develop. If you prefer send text/code/data via US
Mail to the address in the OV manual. Put my name on it somewhere.

Thanks in advance and good coding.
---
 þ EZ 1.30 þ

Date: 10-13-90 (14:35)              Number: 586 / 588 (Echo)
  To: DENNIS EDWARDS                Refer#: 578
From: TIM FARLEY                      Read: NO
Subj: AMRS SETTINGS                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>Assuming this is a '386 box, why would you not want to "swap" your
DE>processes out to EMS?

No good reason.   Just a carry over from the days when we were
running a 286 box.  I've been reluctant to add the /S parameter
because of the lockups lately, but actually I am also anxious to
add it because obviously it will make the system much more
flexible (I can fire up some more tasks and such).

--Tim Farley

Date: 10-13-90 (14:35)              Number: 587 / 588 (Echo)
  To: DENNIS EDWARDS                Refer#: 580
From: TIM FARLEY                      Read: NO
Subj: OMNIHIGH and XMS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

TF>Has OMNIHIGH been made XMS-aware in 4.20?

DE>OMNIHIGH itself always has been able to use XMS. That is why it says:
DE>
DE>          "Could not allocate EMS or upper memory blocks."
DE>
DE>when it fails to find high non-DOS memory. If you can map XMS into the
DE>spot where OMNIHIGH loads high now, and if that will give more room for
DE>TSR load, and if you still end up with 48K left over after loading stuff
DE>then by all means: Do It.

Hmmm...well, for some reason I cannot get this to work on my rig.
I have 60K free continguously free in my UMB area after TSR load,
and OMNIHIGH will NOT load.

I just shelled out and tried it---I have a 60352 byte UMB
available, verified by running a very simple UMB-aware program I
have written.  (And yes, it does release them when done--I can
run it many times with the same result).

But OMNIHIGH 4.13, when run, issues the above referenced error.

DE>But, and it is a BIG BUT, OMNIVIEW does not and cannot use the HMA, which
DE>is a different sort of critter.

Yes, I very much understand that---we've discussed it here
before.

DE> Also consider that, DOS 5.0 is rumored to use XMS for
DE>lots of stuff and that could free up a lot of room for everybody else.

Yes, I think loading up there wouldn't be worth the trouble right
now, especially with the rewrite it would take.  It might be nice
if OV could put some if its buffers up there without much
trouble.

DE>386^Max has the Flex Frame option that allows you to temporarily encroach
DE>on the standard EMS Page Frame in order to initialize your TSRs that are
DE>loaded into high memory. 386-Mate doesn't offer that capability.

FlexFrame sure is a cool option, and it's really quite simple to
use.  The principle behind it (disable EMS, temporarily map some
ram into the page frame, then undo after the TSR goes TSR) is
really so conceptually simple I'm surprised nobody else has done
it before this.

Or maybe I'm just naive and it's really alot more complex than
that?  <grin>

--Tim Farley

(H)elp, (150-588), Message Read Command?